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Анализируется проблема поддержки унаследованного программного обеспечения, возникающая при сопровождении суще- 
ствующих пакетов прикладных программ. Предлагается решение данной проблемы с помощью системной оболочки Вгаіп51огш 
ѵ. 1.0 под М5 ѴѴІпбош, которая позволяет создавать и сопровождать пакеты программ, ранее исполняющиеся под М5-И05. Опи- 
сываются основные механизмы системного обеспечения, реализованные в Вгаіп51огш. Приведены результаты тестирования 
данного инструментального средства. 


За последние несколько десятков лет, вслед- 
ствие интенсивного развития информационных 
технологий и математического моделирования, бы- 
ло создано большое количество универсальных и 
специализированных проблемно-ориентирован- 
ных пакетов прикладных программ (ППП). Созда- 
ние таких пакетов является актуальной задачей, так 
как они фактически являются одной из форм под- 
держки и передачи знаний и технологий. Но объек- 
тивные и субъективные трудности разработки, соз- 
дания и сопровождения таких комплексов про- 
грамм приводят к ряду проблем, одной из которых 
является проблема унаследованного программного 
обеспечения (ПО). Суть данной проблемы состоит 
в том, что в силу ряда причин разработанные про- 
граммы перестают эксплуатироваться, поэтому но- 
вым поколениям исследователей приходится вновь 
тратить значительные ресурсы на создание про- 
граммных пакетов с подобными функциями. Эти 
причины можно классифицировать как субъектив- 
ные и объективные. Субъективные причины об- 
условлены, прежде всего, недостаточным уровнем 
поддержки программного обеспечения пакетов, в 
связи с распадом коллективов разработчиков, ча- 
стичной или полной утратой исходных текстов про- 
грамм. Объективные причины появления унаследо- 
ванного ПО обусловлены самой методологией соз- 
дания ППП. Рассмотрим подробнее объективную 
составляющую проблемы унаследованного ПО. 

Методология разработки проблемно-ориенти- 
рованных программных комплексов рекомендует 
разделять программное обеспечение пакетов на 
функциональную и системную части [1, 2]. Функ- 
циональная часть ППП содержит программную ре- 
ализацию вычислительных алгоритмов для иссле- 
дуемой предметной области, а системная часть - 
программную поддержку разнообразных специфи- 
каций взаимодействия и сервисы: интерфейс и тех- 
нологию диалога пользователя с пакетом, межпро- 
граммные интерфейсы, общие алгоритмы обработ- 
ки данных (в том числе визуализацию данных) и 
т.п. Одной из важных характеристик ПО является 
его жизненный цикл (ЖЦ), который представляет 
собой совокупность этапов (временных интерва- 
лов) разработки, эксплуатации и сопровождения 
созданных программных средств. На ранних ста- 


диях развития как программного и аппаратного 
обеспечения ЭВМ в целом, так и функционально- 
го и системного обеспечения ППП временной ин- 
тервал ЖЦ последних фактически совпадал. Это 
обстоятельство, в частности, объяснялось слабым 
развитием системного обеспечения ЭВМ: ввод 
данных с перфокарт и перфолент, текстоориенти- 
рованный диалог без дополнительных проверок 
вводимых данных, вывод в виде массива чисел, в 
лучшем случае - вывод графиков на бумажный но- 
ситель. С появлением персональных компьютеров 
(ПК) ситуация в развитии системного обеспечения 
существенно изменилась: появился полнотексто- 
вый, а затем и графический интерфейс пользовате- 
ля, диалог в виде меню, возможность распределен- 
ной, удаленной обработки данных и другие техно- 
логии создания, эксплуатации и сопровождения 
ПО. Смена технологий создания системного ПО 
происходила и происходит стремительно, за корот- 
кий промежуток времени. Например, в [3] предла- 
гается расширенное толкование закона Мура, рас- 
пространение его на системное обеспечение ком- 
пьютеров: смена операционной системы каждые 3 
года, изменение интерфейсов каждые 6 лет. В тоже 
время функциональное наполнение пакетов, кото- 
рое в основном определяется вычислительными 
алгоритмами, меняется гораздо медленнее. Хотя и 
здесь появились и развиваются новые технологии 
обработки данных. Уместно отметить такое новое 
направление развития функционального обеспече- 
ния ППП как алгоритмы параллельных высоко- 
производительных вычислений на вычислитель- 
ных системах В нашей стране многопроцессорные 
вычислительные системы мало распространены в 
силу их дороговизны, хотя в последние годы это 
направление развития ПО стимулируется появле- 
нием сравнительно дешевых кластеров ПК. 

В силу разной скорости изменения (обновле- 
ния) системного и функционального наполнения 
ППП проявляется объективная проблема поддерж- 
ки унаследованного ПО. С одной стороны, систем- 
ное ПО перестает поддерживаться в должной мере 
на уровне операционной системы, а с другой сторо- 
ны, функциональное ПО пакетов должно постоян- 
но модернизироваться для синхронизации с жиз- 
ненном циклом системного наполнения ППП. 
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Причем решение данной проблемы существенно 
зависит от той системной информационной техно- 
логии, которую необходимо поддерживать, для по- 
лучения новых функциональных качеств програм- 
мных комплексов. Например, в [4] рассматривалось 
решение проблемы унаследованного ПО с точки 
зрения обеспечения удаленного доступа к вычисли- 
тельным ресурсам. В настоящей статье рассматри- 
вается решение данной проблемы с точки зрения 
поддержки функционального обеспечения, разра- 
ботанного для эксплуатации в операционной систе- 
ме (ОС) М8-005, под ОС М8 \Ѵіпс1оѵл, и предоста- 
вление пользователям соответствующих сервисов. 
В основе решения проблемы лежит идея использо- 
вания при создании системного обеспечения ППП 
минимального набор механизмов (технологий) ин- 
теграции функционального наполнения пакетов, 
которые с течением времени не изменяются, или 
меняются сравнительно мало. 

С целью определения минимальных требова- 
ний к инструментальному средству поддержки уна- 
следованного ПО, проанализируем некоторые тен- 
денции в методологии создания ППП, а так же со- 
стояние системного и функционального обеспече- 
ния ранее разработанных пакетов. При решении 
сложных научных и инженерно-технических про- 
блем существенно повышается значение математи- 
ческого моделирования. Однако аналитические 
возможности последнего ограничиваются, факти- 
чески, классом линейных задач. Решение актуаль- 
ных задач науки и техники требует применение 
ЭВМ и технологии вычислительного эксперимента 
(ВЭ) и, как следствие, разработку и эксплуатацию 
ППП - средство программного обеспечения ВЭ 
[1]. Подобные проблемы возникают и при созда- 
нии и проектирования сложных образцов техники 
и технологии, когда требуется проводить математи- 
ческое моделирование на всех этапах их проекти- 
рования и испытания. В [5] отмечается, что в раз- 
рабатываемом ППП должно быть представлено три 
уровня описания предметной области: 

1) Этап разработки технического задания и техни- 
ческих предложений. На этом этапе в основном 
выполняются оперативные расчеты по упро- 
щенным моделям. 

2) Этап эскизного проектирования. Используют- 
ся апробированные модели среднего уровня 
сложности, но учитывающие распределенность 
объекта (процесса) проектирования. 

3) Этап проведения НИР, получение новых фун- 
даментальных знаний о работе конструкций. 
Создание новых сложных математических мо- 
делей, их апробация. 

При решении как научных, так и инженерно- 
конструкторских задач требуется использовать тех- 
нологию ВЭ, обеспечивая, в первую очередь, тре- 
бования многомодельности и многовариантности 
при проведении вычислительных работ. В после- 
дующих работах [6, 7] перечень этапов технологии 
создания ППП фактически повторяет этапы ВЭ, 


но вместе с тем происходит более углубленное тол- 
кование каждого из этапов, обобщение опыта соз- 
дания конкретных ППП. 

Анализ имеющихся пакетов и средств их по- 
строения позволил выявить следующие закономер- 
ности в их развитии [1,2, 5-8]. 

1) Организация входных/выходных и промежу- 
точных данных функциональных модулей: 

• различного типа файлы; 

• банки данных; 

• различные БД (которые так же являются 
файлами со специальной структурой); 

• хранилища данных; 

• иное, например, хранение неструктуриро- 
ванных данных в различных форматах. 

2) Оформление логических единиц функциональ- 
ного обеспечения пакетов: 

• модули в виде исполняемых или интерпре- 
тируемых программ с произвольным интер- 
фейсом; 

• модули в виде исполняемых или интерпре- 
тируемых программ со специализирован- 
ным интерфейсом; 

• модули-процедуры. 

3) Объединение логических единиц функцио- 
нального обеспечения ППП: 

• с помощью специализированного языка. 

4) Организация работы пользователя с помощью 
различных элементов пакета: 

• входных/выходных данных для функцио- 
нального наполнения; 

• логических единиц функционального на- 
полнения при их запуске; 

• истории ведения исследований различного 
уровня (научных, проектных, оценочных); 

• интерфейса для организации диалога поль- 
зователя с пакетом (текстоориентирован- 
ный, графический интерфейс; формирова- 
ние заданий, пакетов и т.п.). 

Таким образом, с точки зрения пользователя 
при создании инструментального средства созда- 
ния и поддержки унаследованного ПО необходимо 
сохранить технологию вычислительного экспери- 
мента, обратив основное внимание на организа- 
цию взаимодействия функциональных модулей и 
входных/выходных данных. 

С самых общих позиций функциональный мо- 
дуль можно представить как программу, обрабаты- 
вающую по заданному алгоритму входные данные 
и формирующую по определенным правилам вы- 
ходные данные. С учетом этих обстоятельств, про- 
веденный анализ системного обеспечения суще- 
ствующих ППП позволил сформулировать функ- 
циональные требования, которым должно удовле- 
творять создаваемое инструментальное програм- 
мное средство: 
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1) Оперативная классификация (разбиение на 
классы) множества функциональных модулей 

ппп. 

2) Работа с разными совокупностями данных, с 
разными банками данных. 

3) Быстрый запуск функциональных модулей 
ППП, использование предопределенных поль- 
зователем файлов ввода/вывода, которые опи- 
сывают конфигурацию входных/выходных дан- 
ных функциональных модулей. 

4) Создание исполняемых (линейных) цепочек из 
функциональных модулей. 

5) Ведение редактируемого журнала результатов 
запуска функциональных модулей и цепочек 
модулей. 

6) Реализация современного интерфейса систем- 
ной оболочки (\Ѵі п с!о\ѵ- интерфейса) . 

7) Визуализация входных/выходных данных 
функциональных модулей на плоскости. 

Общей составляющей практически во всех пе- 
речисленных выше требованиях к системной обо- 
лочке является задача эффективной организации 
обмена данными. Анализ общих механизмов опе- 
рационных систем типа МБ-БОБ, \Ѵіп16 и \Ѵіп32 
позволил выбрать наиболее простую и надежную 
модель обмена данными: использование системы 
управления файлами и командную строку. Оба ме- 
ханизма взаимодействия программ и данных име- 
ются практически во всех операционных системах, 
причем их использование не требует дополнитель- 
ного анализа и структурирования потоков данных. 
Отметим, что как \Уіп16, так и \Ѵіп32 имеют значи- 
тельно больше возможностей по организации взаи- 
модействия программ, чем ОС МБ-008. 


Рассмотрим подробнее реализацию выше указан- 
ных требований в рамках системной оболочки Вгаіп- 
Біогпг, базовое окно которой представлено на рис. 1. 

Для целей оперативной классификации функ- 
циональных модулей пользователем организуется 
требуемая иерархическая структура папок (катего- 
рий), с соответствующими названиями. С помо- 
щью технологии <Зга§&с1гор из папки «Все модули» 
(где физически находится все множество функцио- 
нальных модулей) осуществляется наполнение па- 
пок категорий, при этом используется механизм 
ссылок на модули. 

Многовариантность вычислительного экспери- 
мента отображается в виде множественности вход- 
ных/выходных данных функциональных модулей. 
Задача сохранения вариантных численных экспери- 
ментов решается двумя способами. Первый способ 
состоит в дублировании имен файлов входных/вы- 
ходных данных, но вариацию их расширений. Са- 
мый простой способ кодирования при этом - номер 
варианта эксперимента совпадает с трехзначным 
числом, полученным из цифр расширения имени 
файла. Второй способ - организация банков данных 
с помощью системной оболочки (рис. 1, «Банки 
данных»). Банки данных, наборы входных/выход- 
ных данных функциональных модулей, организуют- 
ся пользователем. При работе с конкретным банком 
данных требуется определить его как «Текущий». 
При большом количестве вариантных расчетов вто- 
рой способ является предпочтительным. 

Для интеграции функционального модуля, на- 
писанного на языке ТигЬо Разсаі 7.0, в системную 
оболочку используется следующая технология. 
Входные и выходные данные модуля объединяются в 
файлы ввода (іприБз . БхР) и вывода (оиБ- 


7 «Безымянный пакет программ» — Вгаіп$(:огт 
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Рис. 1 . Базовое окно системной оболочки ВгаіпБіогт с загруженным ППП 
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рикз.кхк) (рис. 1, папка «Ввод/вывод»), которые 
получает модуль при запуске от системной оболочки. 
Кроме этого, указывается режим выполнения моду- 
ля: пакетный или интерактивный (ключ Ъаісй). В 
пакетном режиме весь диалог в модуле подавляется. 
Например, запуск модуля рсс03ш_р.ехе в среде 
системной оболочки Вгаіп8іопп в пакетном режиме 
будет выглядеть таким образом: 

рсс03ш_р.ехе --Ьз-і=іпри1;Б . РхР 
--Ъз-о=ои(:ри1:з .кхЬ --Ъз-Ъаксй. 

Структуры текстовых файлов ввода и вывода 
модуля идентичны и состоят из строк, содержащих 
описание вида «ключ=значение». Например, 
/рксзсс1= . . \Ьапкз\Ьазе\Р1:сзсй. 001 
/кгексй= . . \Ьапкз\Ьазе\кгекссІ . 011 
/ѵп<3ѵсй=. . \Ъапкз\Ъазе\ѴЮѴСБ . 001 
/йидзѵсй= . . \Ьапкз\Ьазе\Бидзѵсс1. 050 
В данном файле ввода в строках указаны имена 
файлов, которые выбираются из основного банка 
данных ( . . \Ьапкз\Ьазе\) и в которых содер- 
жаться, в конечном итоге, входные/выходные дан- 
ные функционального модуля. В качестве таких 
данных могут быть указаны простые (текстовые) 
переменные, например: 

Ргодгезз=1 

І1:ега1;іоп=150 

Такие переменные интерпретируются в выпол- 
няемом модуле. Для определения переменных как 
входных данных в теле модуля используется функ- 
ция СекРагаш(рагаш: зкгіпд): зкгіпд, для вы- 
ходных данных - процедура Ри1Рагат(рагаш ( ѵа- 
Іие : зкгіпд) . Для подавления диалога в пакетном 


режиме выполнения модуля используется глобаль- 
ная логическая переменная ВаксШойе. Отметим, 
что файл вывода создается модулем (процедура 8а- 
ѵеОикрикРіІе; ), что является индикатором ус- 
пешного его выполнения. В системной оболочке со- 
провождаются описанием как функциональные мо- 
дули (например, рсс03ш_р.ехе.йезс), так и со- 
держание файлов ввода (рсс03ш_р . ехе . іприкз) п 
вывода (ргоЬа.ехе.оикрик). Например, состав 
файла ввода рсс03ш_р . ехе . іприкз модуля 
рсс03ш_р . ехе следующий: 

/рксзс(1=Зависимость давления цезия 
от температуры резервуара с цезием 

/кгексс1=Работы выхода эмиттера и 
коллектора для электродной пары 

На рис. 2 представлено окно запуска модуля 
рсс03ш_р. ехе. Реализуется пакетный режим вы- 
полнения модуля и указаны конкретные имена 
входного файла. Маршрут не представлен, т.к. 
установлен маршрут текущего банка данных - 
. . \Ьапкз\Ьазе\ (рис. 1). 

Системная оболочка Вгаіп8іогт позволяет фор- 
мировать из множества функциональных модулей в 
интерактивном режиме структуру линейных цепочек 
модулей. Пользователь указывает желаемую после- 
довательность выполнения в пакетном режиме мо- 
дулей и контролирует на основе файлов описания 
модуля и его файлов ввода/вывода (рис. 3). При этом 
формируется «эстафета» данных, которая показыва- 
ет, какие данные (идентификаторы данных) пользо- 
ватель будет иметь перед выполнением конкретного 
модуля цепочки и какие - после выполнения. 


Задайте данные для пакетной работы 




Объект для запуска Входные данные 



Поле 

Значение 


/ріісгсб 

РІС5ССІ.001 


/кгекссі 

кгекссі. 011 


/ѵпсіѵсс) 

ѴМЖО.ООІ 


/сіидіѵссі 

РидІѵссІ.050 

Г” Сохранять промежуточные данные 



Г” Сохранять выходные данные 



Г~ Сохранять входные данные 




Базовое имя для сохранения Прочитать из 

|рсс03т _р . ЕХЕ-2005-7- 1 2- 1 3-50 | рсс03т_р_ТЕС . іприк ~^| 


Сгенерировать | [7 Пакетный режим (иначе — интерактивный) 


Запустить 


Отменить 


Рис. 2. Окно запуска функционального модуля 
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Технические науки 


Свойства цепочки 


*1 


Последовательность 

РСР02.ЕХЕ 

рсс03т_р.ЕХЕ 

_РО307.ЕХЕ 


Добавить... 




Удалить 


Ниже 


Составьте 
последовательность 
выполнения модулей. В 
списках "эстафета" и "данные" 
отображаются изменения, 
вносимые данным модулем. 



Эстафета 


Ы 


И 


2Г* 


Имя цепочки в системе 
ІРСс5_0ид]ѵ_Ѵі5 


Введите имя файла без 
расширения в качестве имени 
цепочки. 


Описание цепочки 
I Рс5 - Ридіѵ - ѴІ5 


Файл ввода/вывода по умолчанию 


’ЬС5 Ридіѵ ѴІ5 ТЕС.ІприІ5 


□ 


ОК I Отменить Применить 


Рис. 3. Окно для формирования цепочки модулей и контроля ее свойств 


Каждый запуск модуля или цепочки модулей 
протоколируется в журнале системной оболочке. 
Журнал - это редактируемый текстовый файл, в 
котором системная оболочка указывает имя испол- 
няемого объекта (модуля или цепочки модулей), 
содержание файлов ввода/вывода и результат вы- 
полнения. Пользователь может добавлять в журнал 
свои комментарии. 

Модули визуализации формируют файлы ви- 
зуализации с ХМЬ-структурой, которые интерпре- 
тируются программой визуализации Ьзѵіз . ехе. 

Таким образом, использование сервиса систе- 
мы управления файлами и механизма командной 
строки позволяет, с одной стороны, минимально 
модифицировать код программ, написанных под 
МЗ-БОЗ и включаемых в ППП, а с другой стороны 
- получить пользователю созданного пакета, под- 
держиваемого системной оболочкой ВгаіпЗіогт, 
интерфейс под ОС М3 \ѴіпсІоѵѵх. 

Первая версия системной оболочки ВгаіпЗіогт 
написана с использование системы визуального 
программирования БефЫ 7. Ядро оболочки пред- 
ставляет независимый модуль Траска§е, управляю- 
щий ППП. Управление пакетом осуществляется с 
помощью методов объекта: управление функцио- 
нальными модулями, управление категориями (для 
классификации модулей), управление цепочками 
модулей, управление файлами ввода/вывода, упра- 
вления банками данных, управление записями в 
журнал и т.д. После подготовки функциональных 
модулей для интеграции в ППП, с помощью Вгаіп- 
Зіогт создается специальная файловая структура, 
которая по мере ее наполнения отображается в ин- 
терфейсе системной оболочки. 


Тестирование системной оболочки Вгаіп- 
Зіогт ѵ. 1.0 проводилось двумя способами. 

Во-первых, были реализованы функции по под- 
держки ППП с помощью моделирующей системы 
(системной оболочки) КОРТЕЗ [8], которая была 
написана на языке Офесі Рахсаі. Кроме интерфей- 
са под ОС М3 \ѴіпсІо\ѵх, существенно расширены 
функции работы с функциональными модулями, с 
входными/выходными данными модулей, функ- 
ции визуализации данных. Появились функции, 
позволяющие создавать и выполнять цепочки 
функциональных модулей. Тестирование систем- 
ной оболочки ВгаіпЗіогт полностью подтвердило 
выполнение функций адекватно функциям моде- 
лирующей системы КОРТЕЗ. 

Во-вторых, был создан пакет программ КІ- 
АЕ_2004 для моделирования процессов в термоэ- 
миссионных системах [9]. В пакете 31 функцио- 
нальный модуль, написанный на языке ТигЬо Рах- 
саі ѵ. 7.0. Банк данных пакета КІАЕ_2004 содержит 
более 100 входных/выходных файлов модулей. 
Структура и содержание данных при интеграции в 
пакет не изменялись, за исключением функцио- 
нальных модулей визуализации. 

При тестировании пакета КІАЕ_2004 были по- 
лучены результаты моделирования, идентичные 
данным [8] , а также новые результаты моделирова- 
ния, изложенные в [9]. 

В заключении можно сделать следующие выводы: 
• Для решения проблемы поддержки унаследо- 
ванного программного обеспечения необходи- 
мо использовать основные механизмы эффек- 
тивного обмена данными, характерные для опе- 
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рационных систем типа М8-Б08, а также 
\Уіп16 и \Ѵіп32: системы управления файлами и 
командную строку. Оба механизма взаимодей- 
ствия программ и данных имеются практически 
во всех операционных системах, причем их ис- 
пользование не требует дополнительного ана- 
лиза и структурирования потоков данных. 

• Механизмы эффективного обмена данными в 
ППП реализованы в системной оболочки Вга- 
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